-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Jaa/is nilpotent #1974
Jaa/is nilpotent #1974
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1974 +/- ##
==========================================
+ Coverage 87.98% 88.01% +0.02%
==========================================
Files 98 98
Lines 36063 36024 -39
==========================================
- Hits 31730 31705 -25
+ Misses 4333 4319 -14 ☔ View full report in Codecov by Sentry. |
…o JAA/is_nilpotent
The new code (or most of it) has been moved into |
Bother! This PR will work only with the revised AA (see PR 1933 there) |
is_unit(a::fqPolyRepMPolyRingElem) even was wrong (it return true for zero)
The generic code is actually faster than those
I am wondering whether all tests related to |
To summarize what I explained earlier in my office: ideally as much of this testing as possible is done in generic "ring conformance tests" which then can be applied to all ring types we define in AA, Nemo, Hecke, Oscar, or elsewhere. In some cases one may still wish to have additional tests to e.g. cover certain corner cases or otherwise specific quirks of an implementation, these then of course should go into the respective package. From that perspective the tests in here are not very special, and could just be dropped here. |
….)) by count(...)
…o JAA/is_nilpotent
Hoping this is now fully complete. The main implementations of |
Usefully faster implementation of
is_nilpotent(::ResElem)
, but it is longer...